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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for the messaging service within the IP Multimedia CN Subsystem 
(IMS) based on the Session Initiation Protocol (SIP), the Session Description Protocol (SDP) and, the Message Session 
Relay Protocol (MSRP) . The document covers immediate messaging, session based messaging and session-based 
messaging conferences, as described in TS 22.340. 

Where possible the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP, SDP and, MSRP, either direcdy, or as modified by 3GPP TS 24.229. 

The present document is applicable to Application Servers (ASs) , Media Resource Function Controllers (MRFCs), 
Media Resource Function Processors (MRFPs) and to User Equipment (UE) providing messaging capabilities. 

This document does not cover the signalling between a MRFC and a MRFP. 
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Protocol". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

[10] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; 

Stage 3". 

[II] 3GPP TS 22.340: "IP Multimedia System (IMS) messaging; Stage 1'. 
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Session Initiation Protocol (SIP)". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 
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[13] RFC 3994 (January 2005): "Indication of Message Composition for Instant Messaging". 

[14] TS 26.141 ' IP Multimedia System (IMS) Messaging and Presence; Media formats and codecs'. 

[15] draft-garcia-mmusic-file-transfer-mech-01.txt (October 2006): "A Mechanism to Enable File 

Transfer with the Session Initiation Protocol". 

Editor's note: The above document cannot be formally referenced until it is published as an RFC. 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

IsComposing information This is a term used to indicate that an indication is sent to the communicating user when 

a user in entering a new message. 

For the purposes of the present document, the following terms and definitions given in TS 22.340 [11] apply: 

Immediate messaging 

Session based messaging 

Session based messaging conferences 

For the purposes of the present document, the [following] terms and definitions given in draft-ietf-simple-message- 
sessions [9] apply: 

Host 

Page-mode messaging 

Session inactivity timer 

Session-mode messaging 

Session-mode messaging conferences 

Visitor 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.147 [10] apply: 

Conferencing Application Server 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CN Core Network 

DM Data manipulator 

DMS Data manipulation server 

IM IP Multimedia 

IMS IP Multimedia CN subsystem 

IP Internet Protocol 

MRFC Media Resource Function Controllers 

MRFP Media Resource Function Processors 

MSRP Message Session Relay Protocol 

SBLP Service Based Local Policy 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UE User Equipment 
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URL Uniform Resource Locator 



Messaging overview 



The basic services for the IP Multimedia core network Subsystem (IMS), as defined in 3GPP TS 24.229 [5], allow a 
user to initiate, modify and terminate media sessions using the Session Initiation Protocol, as defined in RFC 3261 [7]. 
Although these basic mechanisms already allow the exchange of instant messaging information using SIP, this 
functionality can be extended to provide a richer service within the IMS. 

The messaging service within the IM CN subsystem provides the means for a user to send or receive single messages 
immediately to / from another user and to create and participate in a messaging conference with one ore more other 
users. Participants to such message based communication may be internal or external to the home network. 

When to use an immediate message and when to use a session-based messaging session will depend on the application. 

NOTE: Some participants may always use session-based messaging, while others may use immediate messaging 
or a combination of session-based messaging and immediate messaging dependant of the characteristics 
of the messaging session. The criteria are implementation and application specific. 

For immediate messaging the procedures for page-mode messaging, as defined in RFC 3428 [8] or for session-mode 
messaging, as defined in draft-ietf-simple-message-sessions [9] are utilized. When to use an page-mode messaging and 
when to use session-mode messaging session for the purpose of immediate messaging will depend on the application. 

For session-based messaging and session-based messaging conferences, the Message Session Relay Protocol (MSRP) is 
utilized to transport messages. 

The architecture for the 3GPP messaging is specified in 3GPP TS 23.228 [6] and 3GPP TS 23.218 [3]. The 3GPP 
recommended media formats and codecs are specified in 3GPP TS 26.141 [14]. 



5 Protocol using SIP for page-mode messaging 

5.1 Introduction 

5.1 .1 Sending immediate message to multiple recipients 

The UE may be able to send a single immediate message to multiple recipients by including in the MESSAGE request 
the list of URIs (i.e., URI-list) that identify the intended recipients. 

The UE shall create a MESSAGE request in accordance with 3GPP TS 24.229 [5], and it shall also include a multipart 
body in the MESSAGE request. The Request-URI shall be set to the SIP URI of the Application Server that implements 
the role of the List Server. The multipart body shall contain the body carrying the URI-list (in the XML format) whose 
Content-Disposition type is 'recipient-list', and the body that contains the immediate message payload as specified in the 
draft-ietf-sip-uri -list-message [12]. 

The handling of the received response shall be in accordance with 3GPP TS 24.229 [5]. 

5.2 Functional entities 



5.2.1 User Equipment (UE) 



For the purpose of page-mode messaging, the UE shall implement the role of a Participant as described in 

subclause 5.3.1. 
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5.2.2 Application Server (AS) 

As the functional split between the AS and the MRFC is out of scope of the present document, the procedures are 
described for a combined AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a 
proprietary protocol and a proprietary functional split. 

For the purpose of page-mode messaging, an Application Server may implement the role of a List Server as described 
in subclause 5.3.3. An Application Server may implement the role of a Participant as described in subclause 5.3.1 

5.2.3 Media Resource Function Controller (MRFC) 

As the function split between the MRFC and the AS is out of scope of the present document, the procedures for the 
MRFC are described together with those for the AS in subclause 5.2.2. 

5.3 Role 

5.3.1 Participant 

5.3.1.1 General 

For the purpose of page-mode messaging a participant will send a page-mode message using a SIP MESSAGE request 
as defined in RFC 3428 [8] to another participant. 

5.3.1 .2 Sending of an immediate message 

When sending an page-mode message to another participant or to a list server, the participant shall construct and send a 
MESSAGE request in accordance with RFC 3428 [8] and subclause 5.1. 2A.1 of 3GPP TS 24.229 [5]. 

The participant may include in a MESSAGE request an isComposing status message as defined in RFC 3994 [13]. 

The participant shall stop transmitting isComposing status messages if the participant receives a 415 (Unsupported 
Media Type) status code in a response to a MESSAGE request containing the status indication. 

The Request URI shall either be: 

the URI of the other participant; or 

a PSI identifying a group. 

5.3.1 .3 Receiving an immediate message 

Upon receipt of a MESSAGE request, the participant shall perform the procedures as described in RFC 3428 [8] and 
subclause 5.1.2A.2 of 3GPP TS 24.229 [5]. 

NOTE: A MESSAGE request can be used for applications other than immediate messaging (e.g. 

3GPP TS 23.228 [6] subclause 5.4.9), and the handling of received MESSAGE requests for such 
applications is outside the scope of this specification. 

5.3.2 Application Server (AS) 

5.3.2.1 Receiving an immediate message for unregistered Public User Identity 

When an immediate message destined for an unregistered Public User Identity arrives at the user's home network, the I- 
CSCF and S-CSCF perform the actions as specified in 3GPP TS 24.229 [5]. 

If the Public User Identity has services related to unregistered state activated (i.e., hold the MESSAGE request 
temporarily in the network.), the MESSAGE request will be routed to an AS, which processes the request further on. 
The AS may then hold the MESSAGE request and deliver the MESSAGE request when either the UE becomes 
reachable or the validity of the message expires as specified in RFC 3428 [8]. 
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5.3.3 List Server 

5.3.3.1 List server originating case 

In addition to the procedure specified in 5.3.3.2 the Hst server shall follow the procedures of 3GPP TS 24.229 [5] 
subclause 5.7.3 when acting as an originating UA. 

The PSI is used to address a predefined list of URIs. 

The list server shall send a MESSAGE request to each of the entries in the predefined URI list. For each of MESSAGE 
requests the list server shall populate the header fields as follows: 

a) the Request URI header fields set to the URI of one of the entries of the predefined URI list; 

b) the From header field set to the same value as the From header field (excluding the "tag" parameter) that was 
received in the incoming MESSAGE request; 

c) the To header fields set to the same value as the To header field that was received in the incoming MESSAGE 
request; 

d) the P-Charging-Vector header that includees: 

1) the value of the icid parameter if available; and 

2) the value of the orig-ioi parameter if available; 

e) the P-Charging-Function- Addresses header containing the values received in the incoming MESSAGE request 
or, if the P-Charging -Function- Addresses header was not received in the incoming MESSAGE request, indicate the 
values applicable for the list server in the P-Charging-Function- Addresses header; and 

f) the P-Asserted Identity header and Privacy header containing the values received in the MESSAGE request; 
The handling of the 200 (OK) response shall be in accordance with 3GPP TS 24.229 [5]. 

5.3.3.2 List server terminating case 

Upon receipt of a MESSAGE request that includes a PSI in the request URI the list server shall: 

1) check if the PSI is allocated to a predefined URI list and rejects the request in accordance with RFC 3261 [7] if 
it is not allocated. The following actions in this subclause shall only be performed if the distribution list URI is 
allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; 

3) create a 202 (Accepted) response. The response shall be in accordance with the procedures of 

3GPP TS 24.229 [5] subclause 5.7.1.2 in relation to the contents of the P-Charging-Function-Addresses header 
and the P-Charging-Vector header; and : 

a) include the P-Charging- Vector header including: 

i) the value of the icid parameter as received in the MESSAGE request; 

ii) the value of the orig-ioi parameter as received in the MESSAGE request; and 

iii) the term-ioi parameter, indicating the network of the list server; and 

b) include the P-Charging-Function- Addresses header as received in the MESS AGEl request or, if the P- 
Charging-Function-Addresses header was not received in the MESSAGE request, indicate the values 
applicable for the list server in the P-Charging-Function- Addresses header; and 

4) send the 202 (Accepted) response. 
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5.3.3.3 List Server processing the IVIESSAGE URI-list 

Upon receiving the MESSAGE request with the URI-list included in the multipart body, the List Server shall inform the 
UE that it has received the MESSAGE request by returning the 202 (Accepted) response. Subsequently, the List Server 
shall create a MESSAGE request for each intended recipient listed in the URI-list, and it shall insert the immediate 
message payload into the body of each outgoing MESSAGES request. 

When creating the outgoing MESSAGE requests destined for each recipient, the List Server shall follow the procedures 
described in the 3GPP TS 24.229 [5]. The List Server shall populate the header fields of each outgoing MESSAGE 
request as follows: 

the Request-URI set to the SIP URI of the intended recipient; 

the From header field set to the same value as the From header field that was received in the incoming 
MESSAGE request; 

the To header set to the SIP URI of the intended recipient; and 

the remaining headers set to the values as specified in 3GPP TS 24.229 [5] subclause 5.7.3. 

The List Server shall also compose the multipart body of the outgoing MESSAGE request as specified in the draft-ietf- 
sip-uri-list-message [12], and included it in the outgoing MESSAGE request. 

When sending the MESSAGE request to each recipient, and processing the respective responses, the List Server shall 
behave as specified in the 3GPP TS 24.229 [5] subclause 5.7. 



6 Protocol using SIP for session-mode messaging 

6.1 Introduction 

6.2 Functional entities 



6.2.1 User Equipment (UE) 

For the purpose of session-mode messaging, the UE shall implement the role of a Participant as described in 
subclause 6.3.1. 

6.3 Role 
6.3.1 Participant 

6.3.1.1 General 

The participant shall perform SIP related session procedures in accordance with 3GPP TS 24.229 [5] to set up the 
dialog used for session-based messaging. 

6.3.1 .2 Session initiation - mobile originating case 

When the originating participant wishes to engage the terminating participant in a session-mode message session, it 
shall use the call initiation procedure specified in TS 24229 [5]. The Request URI header shall include the URI of the 
terminating participant. 

6.3.1 .3 Session initiation - mobile terminating case 

When the terminating participant receives an initial INVITE request from the originating endpoint proposing a message 
session, the terminating participant shall apply the procedures as specified in 3GPP TS 24.229 [5]. 
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6.3.2 Intermediate Node 

6.3.2.1 General 

The intermediate node shall act as a Routeing B2BUA as specified in subclause 5.7 in TS 24.229 [5].. 

6.3.2.2 Generic procedures for all methods at the intermediate node 

6.3.2.2.1 Intermediate node - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating 
UA. 

6.3.2.2.2 Intermediate node - terminating case 

Upon receipt of an initial request the intermediate node shall follow the procedures of 3GPP TS 24.229 [5] 
subclause 5.7.1.2 in relation to the contents of the P-Charging-Function- Addresses header and the P-Charging- Vector 
header. 

When creating the first response for this initial request, the intermediate node shall: 

1) include the P-Charging- Vector header including: 

a) the value of the icid parameter as received in the initial request; and 

b) the value of the orig-ioi parameter as received in the initial request; and 

c) the term-ioi parameter, indicating the network of the intermediate node; and 

2) include the P-Charging-Function- Addresses header as received in the initial request or, if the P-Charging- 
Function- Addresses header was not received in the initial request indicate the values applicable for the 
conference in the P-Charging-Function- Addresses header. 

When creating responses for an initial INVITE request, the intermediate node shall additionally send the 200 (OK) 
response to the initial INVITE request only after the resource reservation has been completed. 

6.3.2.3 Session Initiation 

6.3.2.3.1 Session initiation - originating case 

The intermediate node shall follow the procedures of 3GPP TS 24.229 [5] at call initiation. 

The intermediate node shall populate the INVITE as specified for a Routeing B2BUA with the following clarification: 

a) the Request URI to the URJ as in the received Request URI: 

b) the To header to the same display name and URI as in the received To header; 

c) the From header sent includes the same display name and URI as in the From header in the received INVITE; 
and 

d) the P-Asserted-Identity header and privacy includes the same information as in the received P-Asserted-Identity 
header and Privacy header; and 

If the intermediate node is not able to establish a TCP connection for the MSRP session the intermediate node shall 
send BYE towards the participant and release the associated recourses. 

6.3.2.3.2 Session initiation - terminating case 

Upon receipt of an INVITE request that includes an the terminating participant URI in the request URI, the intermediate 
node shall: 
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1) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; and 

2) establish the session in accordance with TS 24.229 [5]. 

3) create a 200 (OK) response. 



7 Protocol using SIP for session-mode messaging 

conferences 

7.1 Introduction 

Void. 

7.2 Functional entities 

7.2.1 User Equipment (UE) 

For the purpose of session-mode messaging conferences, the UE shall implement the role of a Participant as described 
in subclause 6.3.1 and the the procedures described in subclause 5.2.1 in 3GPP TS 24.147 [10]. 

7.2.2 Media Resource Function Controller (MRFC) 

For the purpose of session-based messaging conferences, the MRFC shall follow the procedures described in subclause 

5.2.2 in 3GPP TS 24.147 [10]. 

7.2.3 Conferencing Application Server (AS) 

For the purpose of session-based messaging conferences, the AS shall follow the procedures described in subclause 

5.2.3 in 3GPPTS 24.147 [10]. 



8 



Protocol using SDP for session-mode messaging 
and session-mode messaging conferences 



8.1 Introduction 

8.2 Functional entities 
8.2.1 User Equipment (UE) 

For the purpose of session-mode messaging and session-mode messaging conferences, the UE shall implement the role 
of 

an SDP offerer as described in subclause 8.3.1; and 

an SDP answerer as described in subclause 8.3.2. 
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8.2.2 Media Resource Function Controller (MRFC) 

As the function split between the MRFC and the AS is out of scope of the present document, the procedures for the 
MRFC are described together with those for the AS in subclause 8.2.3. 

8.2.3 Application Server (AS) 

As the functional split between the AS and the MRFC is out of scope of the present document, the procedures are 
described for a combined AS and MRFC. The AS and MRFC may either be collocated, or interoperate using a 
proprietary protocol and a proprietary functional split. 

The AS shall implement the role of: 

an intermediate node as described in subclause 8.3.3 when engaged in a session mode messaging conference; or 

an SDP offerer, as described in subclause 8.3.1, and an SDPanswerer, as described in subclause 8.3.2 when 
engaged in a session mode session between a SDP offerer and SDP answerer. 

NOTE: An AS, not performing one of the above specific functionalities, that is on the signalling path for the 
related SIP signalling, is not mandated to terminate the related MSRP. 

8.3 Role 
8.3.1 SDP offerer 

When an SDP offerer wants to create a session mode massaging session, the SDP offerer shall populate the SDP as 
specified in subclause 6.1 in TS 24.229[5]. SDP offerer shall also include: 

a) a media attribute in accordance with draft-ietf-simple-message-sessions [9]; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) the address of the SDP offerer in the path attribute, in accordance with draft-ietf-simple-message-sessions [9]. 

The SDP may also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9] 

The SDP offerer may want to indicate to the other user(s), that the SDP offerer is prepared to receive isComposing 
information, then it shall add the MIME type 'application/ im-iscomposing-nxml to the accept type or access-wrapped 
types attributes. 

At the receipt of the SDPanswer the SDP offerer shall set up a TCP connection (if not already available) when an IP- 
CAN bearer with sufficient QoS is available. 

For file transfer, the SDP shall also include the following media attributes in accordance with draft-garcia-sipping-file- 
transfer-mech-01 [15]: 

a) a=file-selector: and 

b) a=disposition: 

The file-selector attribute shall contain the following selector parameters: 

a) filename-selector and 

b) filesize-selector 

The file-selector attribute may contain the following selector parameters: 

a) filetype-selector and/or 

b) hash-selector 
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If the sender wants the SDP answerer to be able to preview the file, the a=icon: media attribute shall also be included. 

If the sender wants to send a chunk of a file, rather than the complete file, the a=byte-range: media attribute shall also 
be included. 

For file transfer, the SDP shall also include the a=sendonly attribute. 

When the 200 (OK) response for the last MSRP SENT is received, the SDP offerer shall close the MSRP media 
stream(s) for that particular file transfer, by sending a SDP offer where the m line port value for the file transfer media 
stream is set to zero, unless the MSRP media stream is the only stream in the SIP session, in which case a SIP BYE 
request shall be sent in order to terminate the SIP session. 

8.3.2 SDP answerer 

When receiving an SDP offer the SDP answerer shall populate the SDP answer as specified in subclause 6. 1 in TS 
24.229[5]. In addition the answerer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) the MSRP URI of the SDP answerer in the path attribute in accordance with draft-ietf-simple-message- 

sessions [9]. 

The SDPmay also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9]. 

If SDP answerer recieves the MIME type 'application/im-iscomposing-nxml' in the accept-types or accept-wrapped- 
types attribute and the SDP answerer accepts the exchange of isComposing information the SDP answerer shall add the 
MIME type 'application/im-iscomposing-nxml' to the accept-types or access-wrapped types attributes. 

For file transfer, the answerer shall behave in accordance with draft-garcia-sipping-file-transfer-mech-01 [15]. 

8.3.3 Intermediate node 

8.3.3.1 Intermediate node Originating case 

8.3.3.1.1 Sending of a SDP offer 

The intermediate node shall create a SDP offer, which shall include: 

a) a media attribute in accordance with the media attribute received in the received in the SDP offer.; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes as provisioned in the 
intermediate node. The attribute shall be formatted in accordance with draft-ietf-simple-message-sessions [9]; 
and 

c) a MSRP URI of the Intermediate node in the path attribute to be used when the SDP answerer wants to send a 
MSRP message to the conference. The attribute shall be formatted in accordance with draft-ietf-simple-message- 
sessions [9]. 

d) the MIME type 'application/ im-iscomposing-nxml to the accept type or access-wrapped types attributes if it is 
received from the SDP answerer. 

The SDP may also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf simple- 
message-sessions [9]. 

At the receipt of the SDPanswer the Intermediate node shall set up a TCP connection (if not already available) when an 
IP-CAN bearer with sufficient QoS is available. 

For file transfer, the SDP shall also include the following media attributes in accordance with draft-garcia-sipping-file- 
transfer-mech-01 [15]: 
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a) a=file-selector: and 

b) a=disposition: 

The file-selector attribute shall contain the following selector parameters: 

a) filename-selector and 

b) filesize-selector 

The file-selector attribute may contain the following selector parameters: 

a) filetype-selector and/or 

b) hash-selector 

If the incoming SDP offer contains an a=icon: media attribute, it shall be included in the outgoing SDP. 

If the incoming SDP offer contains an a=byte-range: media attribute, it shall be included in the outgoing SDP. 

For file transfer, the SDP shall also include the a=sendonly attribute. 

8.3.3.2 Intermediate node Terminating case 

8.3.3.2.1 Sending of a SDP answer 

The intermediate node shall at the receipt of a SDP offer create a SDP answer. The SDP answer shall include: 

a) a media attribute in accordance with the received media attribute in the SDP offer; and 

b) the supported MIME types in the accept-types or accept-wrapped-types attributes in accordance with draft-ietf- 
simple-message-sessions [9]; and 

c) a MSRP URI in the path attribute to be used when the SDP answerer shall send a MSRP message to the 
conference,. The attribute shall be formatted in accordance with draft-ietf-simple-message-sessions [9]. 

d) the MIME type 'application/ im-iscomposing-nxml to the accept type or access-wrapped types attributes if it is 
received from the SDP offerer. 

The SDPmay also include a max-size attribute. The attribute shall be formatted in accordance with draft-ietf-simple- 
message-sessions [9]. 

9 Protocol using MSRP for session-mode messaging 

and session-mode messaging conferences 

9.1 Introduction 

9.2 Functional entities 
9.2.1 User Equipment (UE) 

9.2.1.1 General 

The UE shall: 

implement the role of an MSRP sender as described in subclause 9.3. 1; and 
implement the role of an MSRP receiver as described in subclause 9.3.2. 
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9.2.2 Application Server (AS) 



As the functional split between the AS and the MRFP is out of scope of the present document, the procedures are 
described for a combined messaging conferencing AS and MRFP. The AS and MRFP may either be collocated, or 
interoperate using a proprietary protocol and a proprietary functional split. 

For the purpose of an AS acting either as: 

an endpoint for session-mode messaging; 

an intermediate node for session-mode messaging; or 

a conferencing AS for session-mode messaging conferences, 
the AS shall implement the role of: 

an intermediate node as described in subclause 9.3.3 when engaged in a session mode messaging conference; or 

a MSRP sender , as described in subclause 9.3.1, and a MSRP receiver, as described in subclause 9.3.2 when 
engaged in a session mode session between a MSRP senderer and MSRP receiver. 

NOTE: An AS, not performing one of the above specific functionalities, that is on the signalling path for the 
related SIP signalling, is not mandated to terminate the related MSRP. 

9.2.3 Media Resource Function Processor (MRFP) 

As the function split between the MRFP and the conferencing AS is out of scope of the present document, the 
procedures for the MRFP are described together with those for the AS in subclause 9.2.2. 

9.3 Role 

9.3.1 MSRP sender 

9.3.1.1 MSRP sender sends a message 

When a MSRP sender wishes to send a message, the MSRP sender shall ensure that the message length is not longer 
than the max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the message 
may be included in one SEND request or chunked into a number of SEND requests. The MSRP sender shall follow the 
procedures and rules as specified in draft-ietf-simple-message-sessions [9], when the MSRP sender fragments a 
message into a number SEND requests. 

The SEND request shall include the Byte-Range header.,The MSRP sender shall populate the Byte-Range header fields 
as follows: 

the range end set to * (interruptable), to make the chunks interuptable, if the SEND request is longer than 2048 
octets; and 

the total field set to the total size of the message. 

The MSRP sender shall create a SEND request in accordance with draft-ietf-simple-message-sessions [9], where the 
value of To-Path is the MSRP URI shall be set to value of path attribute received in a SDP offer or a SDP answer. 

If it is possible to exchange isComposing information, the MSRP sender may include in a SEND request an 
isComposing status message as defined in RFC 3994 [13]. 

9.3.2 MSRP receiver 

When a MSRP receiver receives a SEND request, the MSRP receiver shall parse the SEND request. The MSRP 
receiver shall either send a response including: 
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a) a 200 (OK) status-code , as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND message 
if the parsing was successful; or 

b) an appropriate status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message if the parsing was unsuccessful. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
belonging to the message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if a complete message is received and the Report- 
Success header in the SEND request was set to 'yes'; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in draft-ietf-simple- 
message-sessions [9] if the MSRP receiver can conclude that a complete message is not received and the 
Report-Failure header is set to 'yes' or not included. The criteria to conclude that a complete message is not 
received are specified in draft-ietf-simple-message-sessions [9]. 

9.3.3 Intermediate node 

9.3.3.1 Intermediate node terminating case 

When an intermediate node receives a SEND request, the intermediate node shall: 

1) parse the SEND request and either send a response including: 

a) a 200 (OK) status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message, if the parsing was successful; or 

b) an appropriate status-code, as specified in draft-ietf-simple-message-sessions [9], for the concerned SEND 
message if the parsing was unsuccessful.; and 

2) determine that a complete message has been received. The following actions in this subclause shall only be 
performed if a complete message is received. 

The MSRP receiver shall send a REPORT request if this is explicit or implicit requested in the SEND request(s) 
associated to the same message. It shall either be: 

a) a successful REPORT request including status-code 200 (OK) if the intermediate node concludes that all 
available users on the distribution list has received the complete message or a concerned user has received the 
complete message and the Report-Success header in the SEND request was set to 'yes'; or 

b) an unsuccessful REPORT request including status-code other than 200 (OK) as defined in draft-ietf-simple- 
message-sessions [9] if the intermediate node conclude that a complete message has not been received or that a 
complete message has not been able to be delivered to all available users on the distribution list or to a particular 
member of the distribution list. 

9.3.3.2 Intermediate node originating case 

When an intermediate node wishes to send a message, the intermediate shall ensure that the message length is not 
longer than the max-size attribute, as received in a SDP offer or a SDP answer. Depending on the message length the 
message may be included in one SEND request or chunked into a number of SEND requests. The intermediate node 
shall follow the procedures and rules as specified in draft-ietf-simple-message-sessions [9], when the intermediate node 
fragments a message into a number SEND requests. 

The SEND request shall include the Byte-Range header.,The MSRP sender shall populate the Byte-Range header fields 
as follows: 

the range-end field set to * (interruptable), to make the chunks interuptable, if the SEND request is longer than 
2048 octets; and 

the total field set to the total size of the message. 

The intermediate shall create a SEND request in accordance with draft-ietf-simple-message-sessions [9] with the 
following clarifications: 
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1) set the Report-Success header as received in the SEND request; 

2) set the Report-Failure header as received in the SEND request; and 

3) depending on the received MSRP URI 

a) either send the SEND request to all available user of the conference; or 

b) send the SEND request to one MSRP receiver. 

10 Void 
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Annex A (informative): 

Example signalling flows of messaging service operation 

Editor's note: draft-ietf-simple-message-sessions contains a TBD for lANA registration of a default MSRP port 
number to assist with Firewall traversal. This default port number will be assigned by lANA at 
publication. When the RFC is published the Annex A flow examples need to be updated to show use of 
the default port number in the a=path attribute and the to-path and from-path headers. Current value in the 
examples is 3402 and this should be replaced by the lANA assigned default port in both offer and answer. 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for conferencing within the IP Multimedia CN Subsystem (IMS) based 
on the Session Initiation Protocol (SIP), SIP Events, the Session Description Protocol (SDP) and other protocols. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.228 [6]. 

A.2 Introduction 

A.2.1 General 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [4] subclause 4. 1 applies with the additions specified 
below. 

In order to differentiate between messages for SIP and MSRP, the following notation is used: 

INVITE 



► SIP message 

_ ^^ '^ ^^_ Reliable transport protocol messages 

"^^ (in bold style) 

SEND 



MRSP message (in bold style) 



Figure A.2.2-1 : Signalling flow notation 



A.3 Signalling flows demonstrating immediate messaging 

The signalUng flow for immediate messaging is shown in subclause 10.6 of 3GPP TS 24.228 [4]. 
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A.4 Signalling flows demonstrating session-based 
messaging 

A.4.1 Introduction 

This subclause provides signalling flows for session-based messaging, established both with and without preconditions. 
How the signalling flow for session-based messaging looks like depends on the following: 

a) at what point in time the IP-CAN for the media component (MSRP) is set up; or 

b) whether preconditions and reliable provisional responses are used or not. 

A.4. 2 Establishing a session for session-based messaging 
without preconditions 

Figure A.4.2-1 shows the establishment of an MSRP session between two users without the usage of preconditions and 
reliable provisional responses as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP-CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component 
prior to sending the first MSRP message. 
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UE#1 Home Network 



UE#2 Home Network 



UE#2 Visited Network 



UE#1 



P-CSCF#1 



—1. INVITE ► 

-2. 100 Trying - 



-22. 200 OK — 
— 23.ACK M 



28. Reserve IP- 
CAN bearer for 
media 



S-CSCF#1 



-3. INVITE- 



-4. 1 00 Trying - 



l-CSCF#2 



5. Evaluation of Initial 
Filter Criteria 



-21.200OK- 



-24. ACK- 



-e.lNVITE ► 



-7. lOOTrying- 



S-CSCF#2 



8. HSS query 



-20. 200 OK- 



— 9. INVITE — 
-10. 100 Trying — 



P-CSCF#2 



11. Evaluation of 
Initial Filter Criteria 



-1 9.200 OK- 



-25. ACK- 



.29.TCPsetupi 



■30.SEND- 

I 
■ 31.200 OK" 



-12. INVITE - 



-13. 100 Trying 



-18.200OK- 



-26.ACK- 



UE#2 



-14. INVITE - 



-15. lOO.Trying- 



ie.Reserve IP-CAN 
bearer for media 



-17. 200OK- 



-27.ACK > 



Figure A.4.2-1 : Establishment of MSRP session 



£75/ 



3GPP TS 24.247 version 7.1 .0 Release 7 23 ETSI TS 1 24 247 V7.1 .0 (2007-03) 

The details of the signalling flows are as follows: 

1. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.2-1 

The originating UE wants to initiate a session-based message session with the terminating UE. The 
originating UE creates a local MSRP URL, which can be used for the communication between the two user 
agents. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for the 
MSRP communication. 

Table A.4.2-1 : INVITE request (UE#1 to P-CSCF#1) 



INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip : userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To : <sip : user2_publicl@home2 . net> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip: [5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=message 3402 TCP/MSRP* 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
receieved by UE#1 in the max-size attribute. 



2. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.2-2 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-2: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-3 

The INVITE request is forwarded to the S-CSCF. 
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Table A.4.2-3: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:orig@scscfl. homel .net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
P-Access-Network-Inf o : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A,4.2-4 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 


100 Trying 


















Via: SIP/2. 0/UDP pcsc 


fl 


visitedl 


. net 


branch= 


z9hG4bK240f34.1, 


SIP/2 


0/UDP 


[5555 


: : aaa: bbb: ccc 


:ddd] 


1357; 


comp= 


=sigcomp 


branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 




















Content- 


Length: 



















5. Evaluation of initial filter criteria 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. 

6. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.41-6 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. 
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Table A.4.2-6: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



7. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-7 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.2-7: 100 (Trying) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



8. Cx: User Location Query procedure 

The 1-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

9. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.2-9 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.2-9: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route: <sip: scscf 2 .home2 . net; lr> 

Record-Route : 

P -As sorted- Identity : 

P-Charging-Vector : 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



10. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.2-10 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.2-10: 100 (Trying) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 100 Trying 
















Via: SIP/2. 0/UDP icscf2_s. 


home2 


. net; branch=z 


9hG4bK871 


yl2.1. 


SIP/2. 


0/UDP 


scscfl 


homel . net 


; branch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 






pcscf 1 


visitedl . 


net; branch=z 


9hG4bK240f34. 


1, SIP/2. 


0/UDP 






[5555: 


aaa : bbb : ccc : ddd] 


:1357 


; comp=sigcom]: 


; branch=z 


9hG4bK 


nashds7 




From: 


















To: 


















Call-ID: 


















CSeq: 


















Content-Length: 

















11. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. 

12. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-12 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.2-12: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 66 

Route : <sip:pcscf2.visited2.net;lr> 

Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr>, 
<sip:pcscfl .visitedl . net; lr> 

P -Asserted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 

Privacy : 

From: 

To: 

Call-ID: 

Cseq: 

Contact : 

Allow: 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 

Content-Type : 

Content-Length: (...) 



13. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A,4.2-13 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.2-13: 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 












Via: SIP/2. 0/UDP scsc 


f2 .home2 . net ; branch=z9hG4bK7 64z 


87.1, SIP/2 


0/UDP 


icscf2 


s . home2 . net 


; bran 


ch=z9hG4bK871yl2.1 


, SIP/2. 


0/UDP 




scscf 1 


homel . net; b 


ranch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 




pcscf 1 


visitedl . ne 


t;branch=z9hG4bK240f34. 


1, SIP/2 


.0/UDP 




[5555: 


aaa: bbb: ccc 


:ddd] 


: 1357; comp=sigcomp 


; branch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 













14. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.2-14 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.2-14: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards : 65 
Record-Route : <sip:pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr>, 

<sip: scscfl . homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 
Privacy : 
From; 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 
a= 



15. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A,4.2-15 

The terminating UE sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.2-15: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 

pcscf 1 .visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



16. Reserve IP-CAN bearer for media 

The terminating UE accepts the message session. The terminating UE reserves an IP-CAN bearer for the 
message session media component. 

17. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.2-17 

After reserving an IP-CAN bearer for the message session media component the terminating UE sends a 200 
(OK) response for the INVITE request containing SDP that indicates that the terminating UE has accepted 
the message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP 
SETUP from the originating UE. 
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Table A.4.2-17: 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/2 .0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .vis it edl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route ; <sip;pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>>, <sip; scscf2 . home 2 .net; lr>, 

<sip; scscfl . homel .net;lr>, <sip;pcscfl.visitedl.net;lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From; <sip : userl_publicl@homel . net>; tag=171828 
To: <sip:user2_publicl@home2 . net>; tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 INVITE 

Contact: <sip: [5555: :eee:fff: aaa: bbb] : 8 805; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555:: eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types : text /plain text/html message/cpim 

a=path:msrp: // [5555: : eee : f f f : aaa:bbb] :3402/s234167;tcp 

a=max-size : 65536 



SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at 

UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be receieved by UE#2 in the max-size attribute. 



18. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.2-18 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 
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Table A.4.2-18: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, SIP/ 2. 0/UDP 
pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted-Identity ; John Smith" <sip ; user2_publicl@home2 . net> 

Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 

P-Access-Network-Inf o : 

From; 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



19. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.2-19 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 

Table A.4.2-19: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 
a= 



20. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.2-20 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 
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Table A.4.2-20: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 .homel . net; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : 

P -Asserted- Identity: 

Privacy: none 

P-Charging-Vector : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 



21. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.2-21 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 

Table A.4.2-21 : 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity : 
Privacy : 

P-Charging-Vector: icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso = 023551024 " 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



22. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.2-22 

P-CSCF#1 forwards the 200 (OK) response to the originating UE. 
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Table A.4.2-22: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:pcscf2.visited2.net;lr>, <sip:scscf2. home 2 .net; lr>, 

<sip: scscfl . homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 
P -Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



23. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.2-23 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 

Table A.4.2-23: ACK request (UE#1 to P-CSCF#1) 



ACK sip: [5555: :eee:fff :aaa:bbb] : 8805; comp=sigcomp SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr>, 

<sip: scscf2 . home 2 .net;lr>, <sip:pcscf2.visited2.net;lr> 
From: <sip : userl_publicl@homel .net>;tag=171828 
To : <sip : user2_publicl@home2 .net>;tag=31415 9 
Call- ID: Cb03a0s0 9a2sdfglkj4 90333 
Cseq: 127 ACK 
Content-Length: 



24. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.2-24 

The P-CSCF#1 forwards the ACK request to S-CSCF#1. 

Table A.4.2-24: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip: [5555 : :eee: fff:aaa:bbb] : 8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP pcscfl . visitedl . net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 




[5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp;branch=z9hG4bKnashds7 




Max-Forwards: 69 




P-Access-Networli-Inf o : 




Route: <sip: scscfl .homel . net; lr>, <sip: scscf2 .home2 . net; lr>, <sip:pcscf2 . visited2 . net 


lr> 


From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





25. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.2-25 

The S-CSCF#1 forwards the ACK request to the the S-CSCF#2. 
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Table A.4.2-25: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



26. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.2-26 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 

Table A.4.2-26: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] : 8805; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards : 67 

Route : <sip:pcscf2 . visited2 . net; lr> 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 



27. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.2.27 

P-CSCF#2 forwards the ACK request to the terminating UE. 

Table A.4.2-27: ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/ 2 .0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 




scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 




pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 




[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 




Max-Forwards: 66 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





28. Reserve IP-CAN bearer for media 

The originating UE reserves an IP-CAN bearer for the message session media component. 

29. TCP setup 

The originating UE establishes a TCP connection using the IP-CAN bearers established in step 16 and step 
28 to the host address and the port as specified in the MSRP URL received in the SDP Answer from the 
terminating UE. 

30. MSRP SEND request (UE#1 to UE#2) - see example in table A.4.2-30 

The originating UE sends the first message over the MSRP session with an MSRP SEND request using the 
established TCP connection. 
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Table A.4.2-30: MSRP SEND request (UE#1 to UE#2) 



MSRP d93kswow SEND 




To-path:msrp://[5555: : eee : f f f : aaa:bbb] : 3333/s234167;tcp 




From-path:msrp:// [5555: : aaa:bbb: ccc : ddd] :3402/slll271;tcp 




Message-ID: 8822 




Byte-Range: 1-77/77 




Content-Type: "text/plain" 




those are my principles. If you don't like them I have others 


- Groucho Marx. 


d93kswow$ 





To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

31. MSRP 200 (OK) response (UE#2 to UE#1) - see example in table A.4.2-31 

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response 
using the established TCP connection. 

Table A.4.2-31 : MSRP 200 (OK) response (UE#2 to UE#1) 



MSRP d93kswow 200 OK 

To-path :msrp: // [5555: : aaa : bbb : ccc : ddd] :3402/slll271;tcp 

From-path :msrp ://[5555: :eee:fff:aaa: bbb] :3333/s234167;tcp 

d93kswow$ 



A.4.3 Establishing a session for session-based messaging with 
Intermediate Nodes 

Figure A.4.3- 1 shows the establishment of a MSRP session between two users with intermediate nodes being added to 
the signalling path as well as the first message being sent over the established connection. 

It is assumed that both the originating UE and terminating UE are using an IP -CAN with a separate bearer for SIP 
signalling which means that each UE needs to reserve a new IP -CAN bearer for the message session media component. 
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Figure A.4.3-1 : Establishment of MSRP session with Intermediate Nodes 

The details of the signalhng flows are as follows: 

1. INVITE request (UE#1 to P-CSCF#1) - see example in table A.4.3-1 

The originating UE#1 wants to initiate a session-based message session with the terminating UE#2. UE#1 
creates a local MSRP URL, which can be used for the communication between the two user agents. It builds 
a SDP Offer containing the generated MSRP URL and assigns a local port number for the MSRP 
communication. 
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Table A.4.3-1 : INVITE request (UE#1 to P-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To : <sip:user2_publicl@home2 .net> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi=87654321; portl=7531 

Contact: <sip: [5555: :aaa: bbb : ccc : ddd] : 1357; comp=sigcomp> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



SDP The SDP contains the set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
receieved by UE#1 in the max-size attribute. 



2. 100 (Trying) response (P-CSCF#1 to UE#1) - see example in table A.4.3-2 

The P-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-2: 100 (Trying) response (P-CSCF#1 to UE#1) 



SIP/2.0 100 Trying 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. INVITE request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-3 

The INVITE request is forwarded to the S-CSCF. 
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Table A.4.3-3: INVITE request (P-CSCF#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:orig@scscfl. homel .net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net> 
P-Access-Network-Inf o : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



4. 100 (Trying) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.3-4 

The S-CSCF responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-4: 100 (Trying) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 


100 Trying 


















Via: SIP/2. 0/UDP pcsc 


fl 


visitedl 


. net 


branch= 


z9hG4bK240f34.1, 


SIP/2 


0/UDP 


[5555 


: : aaa: bbb: ccc 


:ddd] 


1357; 


comp= 


=sigcomp 


branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 




















Content- 


Length: 



















5. Evaluation of initial filter criterias 

S-CSCF#1 validates the service profile of this subscriber and evaluates the initial filter criterias. For 
sip:userl_publicl@homel.net S-CSCF#1 has origination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m= 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:asl. homel. net. 

6. INVITE request (S-CSCF#1 to AS#1) - see example in table A.4.3-6 

S-CSCF#1 forwards the INVITE request to the AS#1. 
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Table A.4.3-6: INVITE request (S-CSCF#1 to AS#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Route : <sip : asl . homel .net;lr>, <sip:cb03a0s0 9a2sdfglkj4 90333@scscfl. homel .net; lr> 
Record-Route : <sip:orig@scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net>, <tel : +l-212-555-llll> 
P-Access-Network-Inf o : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4ee] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 
a= 



7. 100 (Trying) response (AS#1 to S-CSCF#1) - see example in table A.4.3-7 

AS#1 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-7: 100 (Trying) response (AS#1 to S-CSCF#1) 



SIP/2.0 100 Trying 
















Via: SIP/2. 0/UDP scsc 


f 1 . homel 


net;branch=z9hG4bK34 4a 


65.1, SIP/2. 


0/UDP 


pcscfl .visitedl 


ne 


t ; branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


::cc 


:ddd] 


1357 ; comp=sigcomp; b 


ranch= 


z9hG4bKnashc 


s7 


From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 

















AS#1 establishes a TCP connection using the IP -CAN bearers established in step 1 to the host address and 
port as specified in the MSRP URL received in the SDP Offer from the originating UE#1. 

8. INVITE request (AS#1 to S-CSCF#1) - see example in table A.4.3-8 

AS#1 sends a new INVITE request to the S-CSCF#1 with the session attribute containing a unique URL for 
the AS#1 to receive media on. 
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Table A.4.3-8: INVITE request (AS#1 to S-CSCF#1) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP asl .homel . net;branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

Route: <sip: cb03a0s0 9a2sdfglk j4 90333@scscf 1 .homel . net; lr> 

P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +l-212-555-llll> 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=234567 

To : <sip:user2_publicl@home2 .net> 

Call- ID: s0 9a233cbsdfglkj4 90303a0 

Cseq: 278 INVITE 

Contact: <sip: [7777: : eee : ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933620 2987933620 IN IP6 7777 :: eee : ddd: ccc : aaa 

s=- 

c=IN IP6 7777 :: eee : ddd: ccc : aaa 

t=0 

m=message 3927 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [7777: : eee : ddd: ccc : aaa] :3927/s222371;tcp 

a=max-size : 6553 6 



SDP The SDP contains the set of offered content types allowed by the policy of network homel in the 

accept-types attribute and indicates the maximum size message that can be receieved by UE#1 and 
allowed by the policy of network homel in the max-size attribute. 



100 (Trying) response (S-CSCF#1 to AS#1) - see example in table A.4.3-9 

S-CSCF#1 sends a 100 (Trying) response provisional response to AS#1. 

Table A.4.3-9: 100 (Trying) response (S-CSCF#1 to AS#1) 



SIP/2 


.0 


100 


Trying 














Via: 


SIP/2. 


0/UDP asl 


homel 


net 


b 


ranch= 


=z9hG4bK240f34 


1 


From: 




















To: 




















Call- 


ID 


















CSeq: 




















Conte 


nt- 


-Len 


gth: 















10. INVITE request (S-CSCF#1 to I-CSCF#2) - see example in table A.4.3-10 

S-CSCF#1 forwards the INVITE request to the I-CSCF#2. As the S-CSCF#1 does not know whether the I- 
CSCF at home2.net is a loose router or not, it does not introduce a Route header. 
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Table A.4.3-10: INVITE request (S-CSCF#1 to l-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards: 69 

Record-Route : <sip:scscfl. homel .net; lr> 
P-As sorted- Identity: 

P-Charging-Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso = 323551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 

3 = 
C= 

t = 

m= 
a= 
a= 



1 1. 100 (Trying) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-11 

I-CSCF#2 sends a 100 (Trying) response provisional response to S-CSCF#1. 

Table A.4.3-11 : 100 (Trying) response (l-CSCF#1 to S-CSCF#1) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, 


SIP/2. 0/UDP 


asl. homel. net;branch=z9hG4bK240f34.1 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





12. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

13. INVITE request (I-CSCF#2 to S-CSCF#2) - see example in table A.4.3-13 

I-CSCF#2 forwards the INVITE request to the S-CSCF#2 that will handle the session termination. 
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Table A.4.3-13: INVITE request (l-CSCF#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s .home2 .net;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Max-Forwards: 68 

Route: <sip: scscf 2 .home2 . net; lr> 
Record-Route : 
P-As sorted- Identity: 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



NOTE: The I-CSCF does not add itself to the Record-Route header, as it has no need to remain in the signalling 
path once the session is established. 

14. 100 (Trying) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-14 

S-CSCF#2 responds to the INVITE request with a 100 (Trying) response provisional response. 

Table A.4.3-14: 100 (Trying) response (S-CSCF#2 to i-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl .homel .net;branch=z9hG4bK240f34 . 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



15. Evaluation of initial filter criterias 

S-CSCF#2 validates the service profile of this subscriber and evaluates the initial filter criterias. For 
sip: user2 publicl@home2.net S-CSCF#2 has termination initial filter criteria with service points of interest 
of Method = INVITE request and SDP m = 'message' and 'msrp' protocol that informs the S-CSCF to route 
the INVITE request to the AS sip:as2. home2.net. 

16. INVITE request (S-CSCF#2 to AS#2) - see example in table A.4.3-16 

S-CSCF#2 forwards the INVITE request to AS#2 
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Table A.4.3-16: INVITE request (S-CSCF#2 to AS#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf 2_s .home2 . net ; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards : 67 

Route : <sip : as2 . home 2 . net; lr>, <sip : s0 9a233cbsclfglkj4 90303a0@scscf2 . home 2 .net; lr> 
Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr> 
P -As sorted- Identity : 
P-Charging-Vector : 
P-Charging-Funct ion-Addresses: ccf=[6666: :b99:c88:d7 7:e66]; ccf=[6666: :a55:b44:c33:d22] 

ecf=[6666::lff:2ee:3dd:4ee]; ecf=[6666:: 6aa:7bb: 8cc: 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



17. 100 (Trying) response (AS#2 to S-CSCF#2) - see example in table A.4.3-17 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-17: 100 (Trying) response (AS#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 
icscf 2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/ 2 .0/UDP 
scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
asl.homel.net;branch=z9hG4bK240f34. 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



18. INVITE request (AS#2 to S-CSCF#2) - see example in table A.4.3-18 

AS#2 sends a new INVITE request to the S-CSCF#2 with the session attribute containing a unique URL for 
the AS#2 to receive media on. 
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Table A.4.3-18: INVITE request (AS#2 to S-CSCF#2) 



INVITE sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP as2 .home2 . net;branch=z9hG4bK348923 . 1 

Max-Forwards: 70 

Route: <sip: s0 9a233cbsdfglk j4 90303a0@scscf 2 .home2 . net; lr> 

P -As sorted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=7871654 

To : <sip:user2_publicl@home2 . net> 

Call- ID: 0s0 9glkj4 903a2sdf33cb03a 

Cseq: 210 INVITE 

Contact: <sip: [9999: : ccc : aaa:bbb: ddd] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933630 2987933630 IN IP6 9999 :: ccc : aaa : bbb : ddd 

s=- 

c=IN IP6 9999: :ccc:aaa:bbb:ddd 

t=0 

m=message 3333 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [9999: : ccc : aaa: bbb: ddd] :3333/s317121;tcp 

a=max-size : 327 68 



SDP The SDP contains the set of offered content types allowed by the policy of network home2 in the 

accept-types attribute and indicates the maximum size message that can be receieved by UE#1 and 
allowed by the policy of network home2 in the max-size attribute. 



19. 100 (Trying) response (S-CSCF#2 to AS#2) - see example in table A.4.3-19 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-19: 100 (Trying) response (S-CSCF#2 to AS#2) 



SIP/2.0 100 Trying 


Via: SIP/2. 0/UDP as2 .home2 . net; branch=z9hG4bK348923 . 1 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



20. INVITE request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-20 

S-CSCF#2 forwards the INVITE request, as determined by the termination procedure. S-CSCF#2 remembers 
(from the registration procedure) the UE Contact address and the next hop CSCF for this UE. 
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Table A.4.3-20: INVITE request (S-CSCF#2 to P-CSCF#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Max-Forwards: 69 

Route : <sip:pcscf2.visitecl2.net;lr> 
Record-Route : <sip:scscf2. home 2 .net; lr> 
P -Asserted- Identity: 
P-Charging-Vector : 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 
Content-Type : 
Content-Length: (...) 



21. 100 (Trying) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-21 

S-CSCF#2 receives a 100 (Trying) response provisional response to the INVITE request. 

Table A.4.3-21 : 100 (Trying) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



22. INVITE request (P-CSCF#2 to UE#2) - see example in table A.4.3-22 

P-CSCF#2 forwards the INVITE request to the terminating UE. 
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Table A.4.3-22: INVITE request (P-CSCF#2 to UE#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net : 5088; comp=sigcomp;branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Max-Forwards: 68 

Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr> 
P-Asserted- Identity: 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



23. 100 (Trying) response (UE#2 to P-CSCF#2) - see example in table A.4.3-23 

UE#2 sends a 100 (Trying) response provisional response to P-CSCF#2. 

Table A.4.3-23: 100 (Trying) response (UE#2 to P-CSCF#2) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



24. Reserve IP-CAN bearer for media 

The terminating UE#2 accepts the message session and. UE#2 reserves an IP-CAN bearer for the message 
session media component. 

25. 200 (OK) response (UE#2 to P-CSCF#2) - see example in table A.4.3-25 

After reserving an IP-CAN bearer for the message session media component, the terminating UE#2 sends a 
200 (OK) response for the INVITE request containing SDP that indicates that UE#2 has accepted the 
message session and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP 
SETUP from AS#2. 
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Table A.4.3-25: 200 (OK) response (UE#2 to P-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK361k21 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 .net; lr> 
Privacy; none 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: <sip : userl_publicl@homel .net>tag=7871654 
To: <sip:user2_publicl@home2 . net>; tag=99945 6 
Call- ID: 0s0 9glkj4 903a2sdf33cb03a 
Cseq: 210 INVITE 

Contact: <sip: [5555: :eee:fff: aaa:bbb] : 8 805; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 29879336302987933630IN IP6 5555 : : eee : f f f : aaa : bbb 

s=- 

c=IN IP6 5555: :eee:fff :aaa:bbb 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types : text/plain text/html message/cpim 

a=path:msrp: // [5555: : eee : f f f : aaa:bbb] :3402/s417121;tcp 

a=max-size : 6553 6 



SDP The SDP contains the set of offered content types supported by UE#2 and desired by the user at 

UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be receieved by UE#2 in the max-size attribute. 



26. 200 (OK) response (P-CSCF#2 to S-CSCF#2) - see example in table A.4.3-26 

P-CSCF#2 forwards the 200 (OK) response to S-CSCF#2. 

Table A.4.3-26: 200 (OK) response (P-CSCF#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net> 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



27. 200 (OK) response (S-CSCF#2 to AS#2) - see example in table A.4.3-27 

S-CSCF#2 forwards the 200 (OK) response to AS#2. 
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Table A.4.3-27: 200 (OK) response (S-CSCF#2 to AS#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP as2 .home2 . net; branch=z9hG4bK348923 . 1 

Record-Route ; 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel ; +l-212-555-2222> 

Privacy ; 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=423551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 
a= 



28. ACK request (AS#2 to S-CSCF#2) - see example in table A.4.3-28 

AS#2 generates a new ACK request and sends it to S-CSCF#2. 

Table A.4.3-28: ACK request (AS#2 to S-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] : 8805; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP as2 . home2 . net ; branch=z9hG4bK348923 . 1 

Max-Forwards: 70 

Route: <sip: scscf 2 .home2 . net; lr>, <sip:pcscf 2 . visited2 . net; lr> 

From: <sip : userl_publicl@homel .net>;tag=7871654 

To: <sip:user2_publicl@home2. net >;tag=22 1777 

Call- ID: 0s0 9glkj4 903a2sdf33cb03a 

Cseq: 210 ACK 

Content-Length: 



29. ACK request (S-CSCF#2 to P-CSCF#2) - see example in table A.4.3-29 

S-CSCF#1 forwards the ACK request to P-CSCF#2. 

Table A.4.3-29: ACK request (S-CSCF#2 to P-CSCF#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

as2.home2.net;branch=z9hG4bK34 8 923. 1 
Max-Forwards: 69 

Route : <sip:pcscf2.visited2.net;lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



30. ACK request (P-CSCF#2 to UE#2) - see example in table A.4.3.30 

P-CSCF#2 forwards the ACK request to UE#2. 
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Table A.4.3-30: ACK request (P-CSCF#2 to UE#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 






Via: SIP/2. 0/UDP pcscf2 .visited2 . net : 5088; comp=sigcomp; branch= 


=z9hG4bK361k21.1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK7 64z87 .1, SIP/ 2 .0/UDP 






as 2 .home2 . net ; branch=z9hG4bK34 8 923 . 1 






Max-Forwards: 68 






From: 






To: 






Call-ID: 






Cseq: 






Content-Length : 







31. TCP setup 



AS#2 establishes a TCP connection using the IP -CAN bearers established in step 24 to the host address and 
port as specified in the MSRP URL received in the SDP Answer from UE#2. 



32. 200 (OK) response (AS#2 to S-CSCF#2) - see example in table A.4.3-32 

AS#2 generates a 200 (OK) response to S-CSCF#2. 

Table A.4.3-32: 200 (OK) response (AS#2 to S-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 . net; branch=z9hG4bK764z87 . 1, SIP/2. 0/UDP 

icscf2_s .home2 . net; branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf 1 .home 1 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Record-Route : <sip:scscf2. home 2 .net;lr>, <sip:scscfl. homel .net; lr> 

P-Asserted-Identity : "John Smith" <sip:user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " 
From: <sip : userl_publicl@homel .net>tag=234567 
To: <sip:user2_publicl@home2.net>;tag=98 98 9823 
Call- ID: s0 9a233cbsdfglkj4 90303a0 
CSeq: 278 INVITE 

Contact: <sip: [9999: : ccc : aaa:bbb: ddd] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933640 2987933640 IN IP6 9999 :: ccc : aaa : bbb : ddd 

s=- 

c=IN IP6 9999: :ccc:aaa:bbb:dddt=0 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [9999: : ccc : aaa: bbb: ddd] :3402/s317122;tcp 

a=max-size : 327 68 



SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types 

attribute and indicates the maximum size message that can be receieved by UE#2 and allowed by 
the policy of network home2 in the max-size attribute. 



33. 200 (OK) response (S-CSCF#2 to I-CSCF#2) - see example in table A.4.3-33 

S-CSCF#2 forwards the 200 (OK) response to I-CSCF#2. 
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Table A.4.3-33: 200 (OK) response (S-CSCF#2 to l-CSCF#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip;user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
Privacy : 
P-Charging-Vector : icid-value"AyretyU0dm+6O2IrT5tAFrbHLso=323551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[6666::b99:c88:d7 7:e66]; ccf=[6666::a55:b4 4:c33:d22]; 

ecf=[6666: :lff:2ee:3dd:4ee] ; ecf=[6666: : 6aa:7bb: 8cc: 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



34. 200 (OK) response (I-CSCF#2 to S-CSCF#1) - see example in table A.4.3-34 

I-CSCF#2 forwards the 200 (OK) response to S-CSCF#1. 

Table A.4.3-34: 200 (OK) response (l-CSCF#2 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK240f34. 1 
Record-Route : 
P -Asserted- Identity: 
Privacy: none 
P-Charging-Vector : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



35. 200 (OK) response (S-CSCF#1 to AS#1) - see example in table A.4.3-35 

S-CSCF#1 forwards the 200 (OK) response to AS#1. 
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Table A.4.3-35: 200 (OK) response (S-CSCF#1 to AS#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP asl .homel . net; branch=z9hG4bK240f 34 . 1 

Record-Route ; 

P -Asserted- Identity: 

Privacy : 

P-Charging-Vector : 

P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22] 

ecf=[5555::lff:2ee:3dd:4ee]; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 



36. ACK request (AS#1 to S-CSCF#1) - see example in table A.4.3-36 

AS#1 generates an ACK request and sends it to S-CSCF#1. 

Table A.4.3-36: ACK request (AS#1 to S-CSCF#1) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP asl . homel . net ; branch=z9hG4bK240f 34 . 1 

Max-Forwards: 70 

Route: <sip: scscfl .homel . net; lr>, <sip: scscf 2 .home2 . net; lr> 

From: <sip : userl_publicl@homel . net>; tag=234567 

To: <sip:user2_publicl@home2.net>;tag=98 98 9823 

Call- ID: s0 9a233cbsdfglkj4 90303a0 

Cseq: 278 ACK 

Content-Length: 



37. ACK request (S-CSCF#1 to S-CSCF#2) - see example in table A.4.3-37 

The S-CSCF#1 forwards the ACK request to S-CSCF#2. 

Table A.4.3-37: ACK request (S-CSCF#1 to S-CSCF#2) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP asl .homel . net;branch= 

z9hG4bK240f34.1 
Max-Forwards: 69 

Route: <sip: scscf 2 .home2 . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



38. ACK request (S-CSCF#2 to AS#2) - see example in table A.4.3-38 

The S-CSCF#2 forwards the ACK request to the AS#2. 
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Table A.4.3-38: ACK request (S-CSCF#2 to AS#2) 



ACK sip: [9999: :ccc:aaa:bbb:ddd] SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 

asl.homel.net;branch=z9hG4bK24 0f34. 1 
Max-Forwards: 68 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



39. TCP setup 



AS#1 establishes a TCP connection to the host address and port as specified in the MSRP URL received in 
the SDP Answer from the AS#2. 



40. 200 (OK) response (AS#1 to S-CSCF#1) - see example in table A.4.3-40 

AS#1 generates a 200 (OK) response and sends it to S-CSCF#1. 

Table A.4.3-40: 200 (OK) response (AS#1 to S-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK344a65 . 1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 

P -Asserted- Identity : 

Privacy : 

P-Charging-Vector: icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso = 023551024 " 

From: <sip : userl_publicl@homel .net>;tag=171828 

To: <sip:user2_publicl@home2 . net>; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

CSeq: 127 INVITE 

Contact: <sip: [7777: : eee : ddd: ccc : aaa] > 

Allow: 

Content-Type : 

Content-Length : 

v=0 

o=- 2987933642 2987933642 IN IP6 7777 :: eee : ddd: ccc : aaa 

s=- 

c=IN IP6 7777 :: eee : ddd: ccc : aaa 

t = 

m=message 3927 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp: // [7777: : eee : ddd: ccc : aaa] :3927/s222372;tcp 

a=max-size : 327 68 



SDP The SDP contains the set of answered content types supported by UE#2 in the accept-types 

attribute and indicates the maximum size message that can be receieved by UE#2 and allowed by 
the policy of network homel in the max-size attribute. 



41. 200 (OK) response (S-CSCF#1 to P-CSCF#1) - see example in table A.4.3-41 

S-CSCF#1 forwards the 200 (OK) response to P-CSCF#1. 
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Table A.4.3-41 : 200 (OK) response (S-CSCF#1 to P-CSCF#1) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] ; 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 
P -Asserted- Identity: 
Privacy : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 

Content-Type : 
Content-Length : 



42. 200 (OK) response (P-CSCF#1 to UE#1) - see example in table A.4.3-42 

P-CSCF#1 forwards the 200 (OK) response to UE#1 

Table A.4.3-42: 200 (OK) response (P-CSCF#1 to UE#1) 



SIP/2.0 200 OK 

Via: S IP /2. 0/UDP [5555: : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 

P -Asserted- Identity : 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 

a= 



43. ACK request (UE#1 to P-CSCF#1) - see example in table A.4.3-43 

The UE responds to the 200 (OK) response with an ACK request sent to the P-CSCF#1. 
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Table A.4.3-43: ACK request (UE#1 to P-CSCF#1) 



ACK sip: [7777: :eee:ddd:ccc:aaa] SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa:bbb: ccc: ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip: scscfl . homel .net; lr> 

From: <sip : userl_publicl@homel .net>;tag=171828 

To: <sip:user2_publicl@home2 . net>; tag=31415 9 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 ACK 

Content-Length: 



44. ACK request (P-CSCF#1 to S-CSCF#1) - see example in table A.4.3-44 

The P-CSCF#1 forwards the ACK request to the S-CSCF#1. 

Table A.4.3-44: ACK request (P-CSCF#1 to S-CSCF#1) 



ACK sip: [7777: :eee:ddd:ccc:aaa] SIP/2.0 


Via: SIP/2. 0/UDP pcscfl .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 


[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 


Max-Forwards: 69 


P-Access-Network-Inf o : 


Route : <sip:scscfl. homel . net ; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length : 



45. ACK request (S-CSCF#1 to AS#1) - see example in table A.4.3-45 

The S-CSCF#1 forwards the ACK request to AS#1. 

Table A.4.3-45: ACK request (S-CSCF#1 to AS#1) 



ACK sip: [7777: : eee 


:ddd 


ccc 


aaa] 


SIP/2.0 










Via: SIP/2. 0/UDP scscfl . homel . n 


et;branch= 


=z9hG4bK344a 


65.1, SIP/2. 


0/UDP 


pcscfl. visitedl 


. net. 


branch=z 


9hG4bK240f34. 


1, SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc : ddd] 


1357 


; comp=sigcomp 


;branch= 


z9hG4bKnashc 


s7 


Max-Forwards : 68 


















From: 


















To: 


















Call-ID: 


















Cseq: 


















Content-Length : 



















46. Reserve IP-CAN bearer for media 

UE#1 reserves an IP-CAN bearer for the message session media component. 

47. TCP setup 

Originating UE#1 establishes a TCP connection using the IP-CAN bearers established in step 46 to the host 
address and port as specified in the MSRP URL received in the SDP Answer from AS#1. 

48. MSRP SEND (UE#1 to AS#1) - see example in table A.4.3-48 

The originating UE sends the first message over the MSRP session with a MSRP SEND request using the 
established TCP connection. 
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Table A.4.3-48: MSRP SEND (UE#1 to AS#1) 



MSRP 34kjf94 SEND 




To-path:msrp:// [7777: : eee : ddd: ccc : aaa] :3927/s222372;tcp 




From-path:msrp:// [5555: : aaa:bbb: ccc : ddd] :3402/slll271;tcp 




Message-ID: 8822 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members 


- Groucho Marx. 


34kjf94$ 





To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

49. MSRP SEND (AS#1 to AS#2) - see example in table A.4.3-49 

AS#1 forwards the first MSRP SEND request to AS#2 over the MSRP session using the established TCP 
connection. 

Table A.4.3-49: MSRP SEND (AS#1 to AS#2) 



MSRP shfsoi3 SEND 




To-path :msrp:// [9999: : ccc : aaa:bbb: ddd] :3333/s317122;tcp 




From-path :msrp: // [7777 : : eee: ddd: ccc: aaa] :3927/s222371;tcp 




Message-ID: 2832 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members - 


- Groucho Marx. 


shfsoi3$ 





To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

50. MSRP SEND (AS#2 to UE#2) - see example in table A.4.3-50 

AS#2 forwards the first MSRP SEND request to UE#2 over the MSRP session using the established TCP 
connection. 

Table A.4.3-50: MSRP SEND (AS#2 to UE#2) 



MSRP 2oid4sf SEND 




To-path :msrp: // [5555 : : eee : fff :aaa:bbb] :3335/s417121;tcp 




From-path :msrp:// [9999: : ccc : aaa : bbb : ddd] :3333/s317121;tcp 




Message-ID: 3311 




Byte-Range: 1-89/89 




Content-Type: "text/plain" 




I will never be a member of a club that accepts people like me as members - 


- Groucho Marx. 


2oid4sf$ 
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To-path: The sender" s remote path. 

From-path: The sender" s local URL. 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

51. MSRP 200 (OK) response (UE#2 to AS#2) - see example in table A.4.3-51 

The receiving UE#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) 
response sent using the established TCP connection. 

Table A.4.3-51: MSRP 200 (OK) response (UE#2 to AS#2) 



MSRP 2oid4sf 200 OK 

To-path :msrp:// [9999: : ccc : aaa : bbb : ddd] :3333/s317121;tcp 

From-path ;msrp;//[5555: :eee;fff;aaa; bbb] ;3335/s417121;tcp 

2oid4sf2 J32ri3$ 



52. MSRP 200 (OK) response (AS#2 to AS#1) - see example in table A.4.3-52 

AS#2 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to AS#1 
using the established TCP connection. 

Table A.4.3-52: MSRP 200 (OK) response (AS#2 to AS#1) 



MSRP shfsoi3 200 OK 

To-path :msrp ;//[7777;;eee; ddd; ccc; aaa] ;3927/s222371;tcp 

From-path ;msrp;// [9999; ; ccc ; aaa ; bbb ; ddd] ;3333/s317122;tcp 

hfsoi3$ 



53. MSRP 200 (OK) response (AS#1 to UE#1) - see example in table A.4.3-53 

AS#1 acknowledges the reception of the MSRP SEND request with a MSRP 200 (OK) response to UE#1 
sent using the established TCP connection. 

Table A.4.3-53: MSRP 200 (OK) response (AS#1 to UE#1) 



MSRP 34kjf94 200 OK 
To-path :msrp : // [555 : : aaa 
From-path :msrp : // [7777 : : 


;bbb 
eee ; 


; ccc 
ddd; 


;ddd] ;3402/slll271;tcp 
ccc;aaa] ; 3927/s222372; t 


cp 







A.4.4 Establishing a session for session-based messaging with 
preconditions 

This signalling flow is not provided as it is the same as the session establishment flows with preconditions in 3GPP TS 
24.228 [4] except that the SDP contents are for setting up MSRP sessions over TCP rather than RTP sessions over 
UDP. 
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A.5 Flows demonstrating session-based messaging 
conferences 

A.5.1 User connecting into a messaging conference 



Visited Network 



UE#1 Home 
Network 



MRFC/AS Home Network 



UE#1 



P-CSCF 



S-CSCF 



l-CSCF 



HSS 



MRFC/AS 



MRFP 



— 1.INVITE- 
-2. 100 Trying 



— 3. INVITE — 
-4. 100 Trying- 



5. Evaiuation of initiai 
Fiiter Criteria 



-14. 200 OK - 



1 5. Authorize QoS resources 



-16. 200 OK 

— 17.ACK ► 



21. Resource 
Reservation 



-18. ACK- 



— 6. iNViTE- 
-7. 100 Trying 



-13.200OK- 



-19.ACK- 



. PSI location query 



-9. iNViTE- 



-10. 100 Trying - 



1 1 . H.248 interaction to create 

conference connection resources for 

UE#1 



-1 2.200 OK- 



-20.ACK- 



■22. TCP setup" 



■23. SEND" 



■24. 200 OK" 



Figure A.5. 1-1 : User connecting into a messaging conference - network IVIRFC/AS is not located in 
user's home network - conference URI resolved by the terminating home network 

Figure A.5. 1-1 shows an user calling into a messaging conference by using a conference URI. The focus of that 
conference is at a MRFC/AS which are located in another network. The conference URI in this example cannot be 
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resolved by the originating home network. In this example Service Based Local Policy and Media Authorisation is 
applied in the visited network. 



The details of the flows are as follows: 

1. INVITE request (UE to P-CSCF) - see example in table A.5.1-1 

A UE wants to join a messaging conference. For this purpose the UE is aware of the related conference URI 
that was obtained by means outside the present document (e.g. via other protocols, such as http). 

The originating UE creates a local MSRP URL, which can be used for communication for the messaging 
conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for 
the MSRP communication. 

The UE sends the INVITE request to the P-CSCF. 

Table A.5.1-1 : INVITE request (UE to P-CSCF) 



INVITE sip:conferencel@home2.net SIP/2.0 

Via: SIP/2.0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp>, <sip:orig@scscfl. homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip:userl_publicl@homel . net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip : userl_publicl@homel . net>; tag=171828 

To: <sip: conferencel@home2 . net> 

Call- ID: Cb03a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip: [5555 : : aaa: bbb: ccc : ddd] : 1357; comp=sigcomp> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [5555: : aaa: bbb: ccc : ddd] :3402/slll271;tcp 

a=max-size : 131072 



SDP The SDP contains a set of content types supported by UE#1 and desired by the user at UE#1 for 

this session in the accept-types attribute and indicates the maximum size message that can be 
receieved by UE#1 in the max-size attribute. 



2. 100 (Trying) response (P-CSCF to UE) - see example in table A.5.1-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response. 

Table A.5.1-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 (Trying) response 






Via: SIP/2. 0/UDP [5555 :: aaa:bbb: ccc : ddd] 


1357, 


comp=sigcomp; branch=z9hG4bKnashds7 


From: 






To: 






Call-ID: 






CSeq: 






Content-Length: 
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3. INVITE request (P-CSCF to S-CSCF) - see example in table A.5.1-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 

Table A.5.1-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip:conferencel@home2.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip:orig@scscfl. homel .net; lr> 
Record-Route : <sip:pcscfl. visitedl. net;lr> 

P-Asserted-Identity : "John Doe" <sip : userl_publicl@homel . net> 
P-Access-Network-Inf o : 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 



4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.5.1-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response. 

Table A.5.1-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 


100 (Trying) 


response 














Via: SIP/2. 0/UDP pcsc 


f 1 .visitedl 


. net 


branch= 


z9hG4bK240f34.1, 


SIP/2 


0/UDP 


[5555 


: : aaa: bbb: ccc 


:ddd] 


1357; 


comp= 


=sigcomp 


•branch= 


=z9hG4bKn 


ashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 




















Content- 


Length: 



















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF to I-CSCF) - see example in table A.5.1-6 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the INVITE request directly to the I-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 
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Table A.5.1-6: INVITE request (S-CSCF to l-CSCF) 



INVITE sip: conferencel@home2.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 . visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "John Doe" <sip:userl_publicl@homel . net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Contact : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 



7. 100 (Trying) response (I-CSCF to S-CSCF) - see example in table A.5.1-7 (related to table A.5.1-6) 

The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response. 

Table A.5.1-7: 100 (Trying) response (I-CSCF to S-CSCF) 



SIP/2.0 100 (Trying) response 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 
pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



8. Public service identity (PSI) location query 

The I-CSCF sends a query to the HSS to find out the MRFC/AS at which the conference has been created. 
The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds 
with the address of the MRFC/AS. 

For detailed message flows see [5]. 
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9. INVITE request (I-CSCF to MRFC/AS) - see example in table A.5.1-9 

I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (8). 
The I-CSCF does not re-write the Request URL 

Table A.5.1-9: INVITE request (I-CSCF to MRFC/AS) 



INVITE sip: conferencel@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards : 67 

Record-Route : <sip:scscfl. homel .net;lr>, <sip:pcscfl. visitedl. net; lr> 
P -Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 



10. 100 (Trying) response (MRFC/AS to I-CSCF) - see example in table A.5.1-10 (related to table A.5.1-9) 

The MRFC/AS responds to the INVITE request (9) with a 100 (Trying) response provisional response. 

Table A.5.1-10: 100 (Trying) response (MRFC/AS to I-CSCF) 



SIP/2.0 100 (Trying) response 












Via: SIP/2. 0/UDP icscf2_s. 


home2 


. net; branch=z 


9hG4bK871 


yl2.1. 


SIP/2. 


0/UDP 


scscf 1 


homel . net; branch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 






pcscf 1 


visitedl. net ;branch=z 


9hG4bK240f34. 


1, SIP/2. 


0/UDP 






[5555: 


aaa : bbb : ccc : ddd] 


:1357 


; comp=sigcomp 


; branch=z 


9hG4bK 


nashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 















1 1 . H.248 interaction to create conference connection resources for UE#1 

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP. 

12. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.5.1-12 (related to table A.5.1-9) 

The MRFC/AS sends a 200 (OK) response for the INVITE request containing SDP that indicates that the 
MRFC/AS has accepted the message session and listens on the MSRP TCP port returned in the path attribute 
in the answer for a TCP SETUP from the originating UE. The MRFC/AS sends a 200 (OK) response final 
response to the INVITE request (9) to the I-CSCF. 
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Table A.5.1-12: 200 (OK) response (M RFC/ AS to l-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s .home2 . net; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 ; ; aaa ; bbb ; ccc ; ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : <sip:scscfl. homel .net;lr>, <s ip:pcscfl. visitedl. net; lr> 
P-Asserted-Identity : "Conference Server" <sip:mrfcl .home2 . net> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[5555::b99:c88:d7 7:e66]; ccf=[5555::a55:b4 4:c33:d22]; 

ecf=[5555::lff:2ee:3dd:4cc]; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: none 
From: 

To: <sip : conf erencel@home2 . net>; tag=314159 
Call-ID: 
CSeq: 

Contact: <sip: conf erencel@home2 .net>; isfocus 
Allow-Events : conference 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s=- 

c=IN IP6 5555 : :aaa:bbb: ccc:ddd 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types :message/cpim text/plain text/html 

a=path:msrp:// [9999: : aaa : bbb: ccc : ddd] :3402/s317122;tcp 

a=max-size : 327 68 



SDP 



The SDP contains a set of offered content types supported by the MRFC/AS for this session in the 
accept-types attribute and indicates the maximum size message that can be receieved by the 
MRFC/AS in the max-size attribute. 



13. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.5.1-13 

The I-CSCF sends a 200 (OK) response final response along the signalling path back to the S-CSCF. 

Table A.5.1-13: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ; branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity: 
P-Charging-Vector : icid-value = "AyretyU0dm+6O2IrT5tAFrbHLso = 023551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Allow: 

Content-Type : 
Content-Length : 
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14. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.5.1-14 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.5.1-14: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-As sorted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: : a55 : b4 4 : c33 : d22 ] 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Allow: 

Content-Type : 
Content-Length : 



15. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. 

16. 200 (OK) response (P-CSCF to UE) - see example in table A.5.1-16 

The P-CSCF forwards the 200 (OK) response final response including the media authorisation token to the 
session originator. 

Table A.5.1-16: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/ 2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357; comp=sigcomp; branch=z9hG4bKnashds7 

Record-Route : <sip:scscfl. homel . net; lr>, <sip:pcscfl .visitedl . net : 7531; Ir; comp=sigcomp> 

P-Asserted- Identity: 

Privacy : 

P-Media-Authorization : 

0020000100100101706466322e76697369746564322e6e6574000c020139425633303732 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Allow: 

Content-Type : 
Content-Length : 
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17. ACK request (UE to P-CSCF) - see example in table A.5.1-17 

The UE starts the media flow for this session, and responds to the 200( OK) response (16) with an ACK 
request sent to the P-CSCF. 

Table A.5.1-17: ACK request (UE to P-CSCF) 



ACK 


sip: conference l@home2 .net :2342 SIP/2 















Via: 


SIP/2. 0/UDP [5555: :aaa 


:bbb 


ccc 


ddd] 


1357; comp=sig 


comp; branch= 


z9hG4bK 


nas 


hds7 


Max- 


^^orwards : 70 




















Rout 


e: <sip : pcscf 1 . visitedl 


. net 


7531;lr; 


::omp=sigcomp>. 


<sip 


:scscfl 


. homel . 


net 


;lr> 


From 


: <sip:userl_publicl@homel . net>. 


tag 


=171828 












To: 


<sip: conferencel@home2 . 


net> 


tag= 


=314159 












Call 


-ID: cb03a0s09a2sdfglkj 


490333 
















Cseq 


: 127 ACK 




















Content-Length: 





















18. ACK request (P-CSCF to S-CSCF) - see example in table A.5.1-18 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.5.1-18: ACK request (P-CSCF to S-CSCF) 



ACK sip:conferencel@home2.net :2342 SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route: <sip: scscfl .homel . net; lr> 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



19. ACK request (S-CSCF to I-CSCF) - see example in table A.5.1-19 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the ACK request directly to the 1-CSCF in the destination 
network. 

As the S-CSCF does not know whether the 1-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 

Table A.5.1-19: ACK request (S-CSCF to 1-CSCF) 



ACK sip : conference 


l@h 


ome2 . 


net 


2342 SIP/2 











Via: SIP/2. 0/UDP scsc 


f 1 . homel 


net; branch= 


=z9hG4bK332b23.1, SIP/2. 


0/UDP 


pcscfl .visitedl 


. ne 


: ; branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc 


:ddd] 


: 1357; comp=sigcomp; b 


ranch= 


z9hG4bKnashc 


s7 


Max-Forwards: 68 


















From: 


















To: 


















Call-ID: 


















Cseq: 


















Content-Length : 
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20. ACK request (I-CSCF to MRFC/AS) - see example in table A.5.1-20 

I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (8). The 
I-CSCF does not re-write the Request URL 

Table A.5.1-20: ACK request (I-CSCF to MRFC/AS) 



ACK sip:conferencel@home2.net :2342 SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ; branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 
scscf 1 .homel . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 
pcscf 1 . visitedl . net ; branch=z9hG4bK240f 34 .1, SIP/ 2 .0/UDP 
[5555 : : aaa : bbb : ccc : ddd] ; 1357 ; comp=sigcomp; branch=z9hG4bKnashds7 

Max-Forwards ; 67 

From; 

To: 

Call-ID: 

Cseq: 

Content-Length : 



21. Reserve IP-CAN bearer for media 

The UE reserves an IP -CAN bearer for the message session media component. 

22. TCP setup 

Originating UE establishes a TCP connection using the IP-CAN bearers established in step 21 to the host 
address and port as specified in the MSRP URL received in the SDP Answer from MRFC/AS. 

23. MSRP SEND request (UE to MRFP) - see example in table A.5.1-23 

The originating UE sends the first me.ssage over the MSRP session with an MSRP SEND request using the 
established TCP connection. 

Table A.5.1-23: MSRP SEND request (UE to MRFP) 



MSRP a97ghjut SEND 

To-path:msrp:// [9999: : ccc : aaa: bbb: ddd] :3402/s317122;tcp 

From-path:msrp:// [5555: : aaa: bbb: ccc: ddd] :3402/slll271;tcp 

Message-ID: 9972 

Byte-Range: 1-77/77 

Content-Type: "text/plain" 

tliose are my principles. If you don't lilce tliem I liave otlners - Grouclno Marx. 

a97glnjut$ 



To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

24. MSRP 200 (OK) response (MRFP to UE) - see example in table A.5.1-24 

The MRFP acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response using the 
established TCP connection. 

Table A.5.1-24: MSRP 200 (OK) response (MRFP to UE) 



MSRP a97glnjut 200 OK 

To-patln:msrp:// [9999: : ccc : aaa : bbb : ddd] :3402/s317122;tcp 
From-patln :msrp://[5555: :aaa: bbb : ccc : ddd] :3402/slll271;tcp 
a97glrLJut$ 
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A. 5. 2 MRFC/AS invites a user to a messaging conference 

Figure A.5.2-1 shows an MRFC/AS inviting a user to a messaging conference. The invitation is sent as a resuh of 
userl @homel.net sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than 
user's S-CSCF. The flows for inviting a user to a conference using REFER are shown in TS 24.147 [10]. In this 
example Service Based Local Policy and Media Authorisation is applied in the visted network. 
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UE#1 Home Network 



UE#2 Home Network 



MRFP 



M RFC/AS 



UE#2 Visited Network 



l-CSCF 



-1. INVITE > 



-2. lOOTrying- 



S-CSCF 



S.HSSquery 



-16. 200OK- 



—4. INVITE ► 

-5. 100 Trying— 



P-CSCF 



6. Evaluation of 
initial Filter Criteria 



-15. 200OK- 



-17. ACK- 



20. H.248 interaction to create 

conference connection 

resources for UE#2 



—7. INVITE ► 

-8. 100 Trying— 



UE#2 



9. Authorize QoS 
resources 



-14. 200OK- 



-18. ACK ► 



21.TCPsetupi 



■22. SEND 1 



■ 23. 200 OKi 



-10. INVITE > 



-11. 100 Trying — 



12. Resource 
Reservation 



-13. 200OK- 



-19. ACK ► 
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Figure A.5.2-1 : MRFC/AS inviting a user to a messaging conference - IVIRFC/AS routes directly to I- 

CSCF 

The details of the flows are as follows: 

1 . INVITE request (MRFC/AS to I-CSCF) - see example in table A,5.2-l 

In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. 
As a result of a DNS query, it has received the address of the I-CSCF as the next hop. 

The MRFC/AS invites a user to a messaging conference as it received a REFER request from another user. 

The MRFC/AS creates a local MSRP URL, which can be used for communication for the messaging 
conference. It builds a SDP Offer containing the generated MSRP URL and assigns a local port number for 
the MSRP communication. In this example Service Based Local Policy and Media Authorisation is applied in 
the visited network. 



Table A.5.2-1 : INVITE request (IVIRFC/AS to I-CSCF) 



INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP mrf cl .homel . net; branch=z9hG4bK23273846 

Max-Forwards; 70 

P -Asserted- Identity ; <sip;conferencel@mrfcl. homel . net> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net 

Privacy; none 

From; <sip ; conference l@mrfcl . homel .net>;tag=171828 

To ; <sip ; user2_publicl@home2 . net> 

Call- ID; Cb03a0s0 9a2sdfglkj4 90333 

Cseq; 127 INVITE 

Refer red-By ; <sip ; userl_publicl@homel . net> 

Contact; <sip;conferencel@mrfcl. homel .net>; isfocus 

Allow; INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 

Allow-Events ; conference 

Content-Type; application/sdp 

Content-Length; (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 ; ; abc ; def ; abc ; def 

s=- 

c=IN IP6 5555; ;abc;def ;abc;def 

t=0 

m=message 3402 TCP/MSRP * 

a=accept-types ;message/cpim text/plain text/html 

a=path;msrp; // [5555; ; abc ; def ; abc ; def ] ;3402/slll271;tcp 

a=max-size ; 327 68 



SDP The SDP contains a set of content types supported by the MRFC/AS for this session in the accept- 

types attribute and indicates the maximum size message that can be receieved by the MRFC/AS in 
the max-size attribute. 



2. 100 (Trying) response (I-CSCF to MRFC/AS) - see example in table A.5.2-2 

The I-CSCF responds to the INVITE request with a 100 (Trying) provisional response. 

Table A.5.2-2: 100 (Trying) response (I-CSCF to MRFC/AS) 



SIP/2.0 100 Trying 

via; SIP/ 2. 0/UDP conferencelgmrf cl .homel . net; branch=z9hG4bK23273 84 6 

From; 

To; 

Call-ID; 

CSeq; 

Content-Length; 



3. Cx: User Location Query procedure 
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The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228[1 1]. 

4. INVITE request (I-CSCF to S-CSCF) - see example in table A.5.2-4 

The INVITE request is forwarded to the S-CSCF. 

Table A.5.2-4: INVITE request (I-CSCF to S-CSCF) 



INVITE sip:user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2 .home2 .net;branch=z9hG4bK241dl7 . 2, SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK2327 384 6 
Max-Forwards; 69 
P-Asserted- Identity: 
P-Charging-Vector : 
Privacy ; 
From; 
To; 

Call-ID; 
Cseq; 

Referred-By ; 
Contact ; 
Allow; 

Allow-Events ; 
Content-Type ; 
Content-Length; (...) 



5. 100 (Trying) response (S-CSCF to I-CSCF) - see example in table 6.2.2,2-5 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response. 

Table 6.2.2.2-5: 100 (Trying) response (S-CSCF to I-CSCF) 



SIP/2.0 100 Trying 

Via; SIP/2. 0/UDP icscf 2 . home2 . net ; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273 84 6 
From; 
To; 

Call-ID; 
CSeq; 
Content-Length; 



6. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

7. INVITE request (S-CSCF to P-CSCF) - see example in table A.5.2-7 

S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P-CSCF 
assigned for UE#2 and routes message there. 
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Table A.5.2-7: INVITE request (S-CSCF to P-CSCF) 



INVITE sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 . net;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf 2 .home2 . net; branch=z9hG4bK241dl7 .2, SIP/ 2 .0/UDP 

mrfcl.homel.net;branch=z9hG4bK2327384 6 
Max-Forwards: 68 

Record-Route : <sip:scscfl. homel .net; lr> 
P -Asserted- Identity: 

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy : 
From: 
To: 

Call-ID: 
Cseq: 

Ref erred-By : 
Contact : 
Allow: 

Allow-Events : 

P-Called-Party-ID: <sip: user2_publicl@home2 . net> 
Content-Type : 
Content-Length: (...) 



100 (Trying) response (P-CSCF to S-CSCF) - see example in table A.5.2-8 

The P-CSCF responds to the INVITE request (6) with a 100 (Trying) provisional response. 

Table A.5.2-8: 100 (Trying) response (P-CSCF to S-CSCF) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf 2 .home2 . net;branch=z9hG4bK332b23 . 1, 


SIP/2. 0/UDP 


icscf 2 .home2 . net ; branch=z9hG4bK241dl7 .2, SIP/ 2 .0/UDP 




mrfcl .homel . net ; branch=z9hG4bK2327 384 6 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





9. Authorize QoS resources 

The P-CSCF authorizes the resources necessary for this session. 
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10. INVITE request (P-CSCF to UE#2) - see example in table A.5.2-10 

P-CSCF forwards the request to UE#2 including the Media Authorisation token. 

Table A.5.2-10: INVITE request (P-CSCF to UE#2) 



INVITE sip: [5555: :eee:fff :aaa:bbb] : 8805; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp; branch=z9hG4bK240f 34 . 1 SIP/2. 0/UDP 

scscf2.home2.net;branch=z9hG4bK332b23. 1, S IP /2. 0/UDP 

icscf 2 .home2 . net ; branch=z9hG4bK241dl7 .2, SIP/ 2 .0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273 84 6 
Max-Forwards : 67 

Record-Route : <sip:pcscf2 .visited2 . net : 5088; Ir; comp=sigcomp>, <sip: scscf2 . home 2 . net ; lr> 
P -Asserted- Identity : 
Privacy : 

P-Media-Authorization: 0020000 100 100 10 170 64 663 12e68 6f6d65312e6e6574 0c02 01333 1533 1343 63231 
From: 
To: 

Call-ID: 
Cseq: 

Ref erred-By : 
Contact : 
Allow: 

Allow-Events : 
P-Called-Party-ID : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
a= 
a= 

a= 



1 1. 100 (Trying) response (UE#2 to P-CSCF) - see example in table A.5.2-11 

UE#2 responds to the INVITE request (10) with a 100 (Trying) provisional response. 

Table A.5.2-11 : 100 (Trying) response (UE#2 to P-CSCF) 



SIP/2.0 100 Trying 




Via: SIP/2 .0/UDP pcscf 2 .vis it ed2 . net : 5088; comp=sigcomp; branch=z9hG4bK240f 34 


1 SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 




icscf 2 .home2 . net ; branch=z9hG4bK241dl7 .2, SIP/2 . 0/UDP 




mrfcl.homel.net;branch=z9hG4bK23273 84 6 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





12. Resource reservation 

After determining the media streams, UE#2 initiates the reservation procedures for the resources needed for 
this session. 



13. 200 (OK) response (UE#2 to P-CSCF) - see example in table A.5.2-13 (related to table A.5.2-10) 

After reserving an IP -CAN bearer for the message session media componentthe receipt of the MSRP 200 
(OK) response to the MSRP VISIT request, the terminating UE#2 sends a 200 (OK) response for the INVITE 
request containing SDP that indicates that UE#2 has successfully visited AS#2. accepted the message session 
and listens on the MSRP TCP port returned in the path attribute in the answer for a TCP SETUP from the 
MRFC/AS. 
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Table A.5.2-13: 200 (OK) response (UE#2 to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net : 5088; comp=sigcomp; branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

scscf 2 .home2 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 

icscf 2 .home2 . net ; branch=z9hG4bK241dl7 .2, SIP/2 .0/UDP 

mrfcl.homel.net;branch=z9hG4bK2327384 6 
Record-Route : <sip:pcscf2 .visited2 . net ; 5088; Ir; comp=sigcomp>, <sip; scscf2 . home 2 . net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy; none 
From; 

To; <sip;user2_publicl@home2 .net>; tag=314159 
Call-ID; 

CSeq; 127 INVITE 

Contact; <sip; [5555; ;eee;fff; aaa;bbb] ; 8 805; comp=sigcomp> 
Content-Length ; 

Allow; INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Content-Type; application/sdp 
Content-Length; (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 ; ; eee ; f f f ; aaa ;bbb 

s=- 

c=IN IP6 5555; ;eee;fff ;aaa;bbb 

t = 

m=message 3402 TCP/MSRP * 

a=accept-types ; text/plain text/html message/cpim 

a=path;msrp;// [5555; ; eee ; f f f ; aaa ; bbb] ;3402/s417121;tcp 

a=max- s ize; 65536 



SDP 



The SDP contains a set of offered content types supported by UE#2 and desired by the user at 
UE#2 for this session in the accept-types attribute and indicates the maximum size message that 
can be receieved by UE#2 in the max-size attribute. 



14. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.5.2-14 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 



Table A.5.2-14: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via; SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

icscf 2 .home2 . net ; branch=z9hG4bK241dl7 .2, SIP/2 .0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273 84 6 
Record-Route ; <sip;pcscf2.visited2.net;lr>, <sip;scscf2. home 2 .net; lr> 
P-Asserted-Identity ; "John Smith" <sip;user2_publicl@home2 . net> 
P-Access-Network-Inf o ; 

P-Charging-Vector; icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " 
Privacy ; 
From; 
To; 

Call-ID; 
CSeq; 
Contact ; 
Allow; 

Content-Type ; 
Content-Length ; 
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15. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.5.2-15 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to I-CSCF. 

Table A.5.2-15: 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2 . home2 . net ;branch=z9hG4bK241dl7 . 2, SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK2327 384 6 
Record-Route : 

P-Asserted-Identity : "John Smith" <sip : user2_publicl@home2 . net>, <tel : +l-212-555-2222> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024 " ; orig-ioi=homel .net; 

term-ioi=home2 . net 
P-Charging-Funct ion-Addresses: ccf=[5555: :b99:c88:d7 7:e66]; ccf=[5555: :a55:b44:c33:d22]; 

ecf=[5555: : If f : 2ee : 3dd: 4cc] ; ecf=[5555: : 6aa: 7bb: Sec : 9dd] 
Privacy : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
a= 

a= 

a= 



16. 200 (OK) response (I-CSCF to MRFC/AS) - see example in table A.5.2-16 

The 1-CSCF forwards the 200 (OK) response final response to the session originator. 

Table 6.2.2.2-16: 200 (OK) response (I-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrf cl . homel . net ; branch=z9hG4bK23273846 

Record-Route : 

P -As sorted- Identity: 

Privacy : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow: 

Content-Type : 

Content-Length : 
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17. ACK request (MRFC/AS to S-CSCF) - see example in table A.5.2-17 

The MRFC/AS responds to the 200 (OK) response (16) with an ACK request sent to the S-CSCF. 

Table A.5.2-17: ACK request (MRFC/AS to S-CSCF) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP mrf cl . homel . net ; branch=z9hG4bK23273846 




Max-Forwards: 70 




Route: <sip: scscf2 .home2 .net; lr>, <sip:pcscf 2 . visitecl2 . net 


lr> 


From: <sip : conferencelSmrf cl . homel . net>; tag=171828 




To: <sip:user2_publicl@home2 . net>; tag=31415 9 




Call-ID: Cb03a0s0 9a2sdfglkj4 90333 




Cseq: 127 ACK 




Content-Length: 





18. ACK request (S-CSCF to P-CSCF) - see example in table A.5.2-18 

The S-CSCF forwards the ACK request to the P-CSCF. 

Table A.5.2-18: ACK request (S-CSCF to P-CSCF) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1, 


SIP/2. 0/UDP 


mrfcl .homel . net ; branch=z9hG4bK23273 84 6 




Max-Forwards: 69 




Route : <sip:pcscf2.visited2.net;lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





19. ACK request (P-CSCF to UE#2) - see example in table A.5.2-19 

The P-CSCF forwards the ACK request to the UE#2. 

Table A.5.2-19: ACK request (P-CSCF to UE#2) 



ACK sip: [5555: :eee:fff :aaa:bbb] :8805;comp=sigcomp SIP/2.0 




Via: SIP/ 2 .0/UDP pcscf 2 . visited2 . net : 5088; comp=sigcomp;branch=z9hG4bK240f 34 . 1, 


SIP/2. 0/UDP 


scscf 2 .home2 . net ; branch=z9hG4bK332b23 .1, SIP/ 2 .0/UDP 




mrfcl .homel . net ; branch=z9hG4bK2327 384 6 




Max-Forwards: 68 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length : 





20. H.248 interaction to create conference connection resources for UE#2 

MRFC initiates a H.248 interaction to create an connection point for UE#2 in MRPP. 

21. TCP setup 

MRFP establishes a TCP connection using the IP-CAN bearers established in step 12 to the host address and 
port as specified in the MSRP URL received in the SDP Answer UE#2. 

22. MSRP SEND request (MRFP to UE#2) - see example in table A.5.1-22 

The MRFP sends the first message over the MSRP session with an MSRP SEND request using the established 
TCP connection. 
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Table A.5.1-22: MSRP SEND request (MRFP to UE#2) 



MSRP y56hkseg SEND 

To-path:msrp:// [5555: : eee : f f f : aaa:bbb] :3402/s417121;tcp 

From-path:msrp: // [5555: : abc : def : abc : def ] :3402/slll271;tcp 

Message-ID: 10568 

Byte-Range: 1-89/89 

Content-Type: "text/plain" 

I will never be a member of a club that accepts people like me as members - Groucho Marx. 

y56hkseg$ 



To-path: The sender" s remote path 

From-path: The sender" s local URL 

Message-ID: A unique message ID for MSRP message. 

Byte-Range: The Byte Range for this message. 

Content-Type: The format of the body of the request. 

23. MSRP 200 (OK) response (UE#2 to MRFP) - see example in table A.5.1-23 

The terminating UE acknowledges the reception of the MSRP SEND request with an MSRP 200 (OK) response 
using the established TCP connection. 

Table A.5.1-23: MSRP 200 (OK) response (UE#2 to MRFP) 



MSRP y56hkseg 200 OK 

To-path :msrp: // [5555: : eee : f f f : aaa:bbb] :3402/s417121;tcp 
From-path :msrp: // [5555: : abc : def : abc : def ] :3402/slll271;tcp 
y56hkseg$ 
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